Internet Surfer 2.0

home *** CD-ROM | disk | FTP | other *** search

/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / text / mac / faqs.125 < prev next >

Wrap

Text File | 1996-02-12 | 29KB | 682 lines

Frequently Asked Questions (FAQS);faqs.125 The default value for these resources are set to CopyFromParent. This is interpreted as the DefaultColormapOfScreen(), DefaultDepthOfScreen() and the default visual of the screen if the widget has no parent -- i.e. it is an applicationShellWidgetClass and the root of your widget tree. If the parent of the widget is not null, then the shell copies colormap and depth from its parent and uses CopyFromParent as the visual. ---------------------------------------------------------------------- 8. I've done all the above and I still get a BadMatch error. Why? ---------------------------------------------------------------------- Some resource converters improperly cache references. This was especially true of X11R3 and earlier versions of Motif. ---------------------------------------------------------------------- 9. Why doesn't my widget get destroyed when I call XtDestroyWidget()? ---------------------------------------------------------------------- See section 2.8 of the Xt specification. It eventually does get destroyed, just not immediately. The Intrinsics destroy a widget in a two-phase process. First it and all of its children have a flag set that indicate it is being destroyed. It is then put on a list of widgets to be destroyed. This way any pending X events or further references to that widget can be cleaned up before the memory is actually freed. The second phase is then performed after all callbacks, event handlers, and actions have completed, before checking for the next X event. At this point the list is traversed and each widget's memory is actually free()'d, among other things. As some further caveats/trivia, the widgets may be destroyed if the Intrinsics determine that they have no further references to the widgets on the list. If so, then the phase 2 destruction occurs immediately. Also, if nested event loops are used, widgets placed on the destroy list before entering the inner event loop are not destroyed until returning to the outer event loop. ---------------------------------------------------------------------- 10. How do I exit but still execute the DestroyCallbacks? ---------------------------------------------------------------------- The problem is if a simple and entirely reasonable approach to exiting an application is used, such as calling exit() directly, then a widget may not have a chance to clean up any external state -- such as open sockets, temporary files, allocated X resources, etc. (this code for simplicity reasons assumes only a single toplevel widget): Widget ToplevelGet (gw) Widget gw; /* widget to find toplevel */ { Widget top; for (top = gw; XtParent (top); top = XtParent (top)) /* empty */; return (top); } void ExitCallback (gw, closure, call_data) Widget gw; /* widget */ XtPointer closure; /* data the app specified */ XtPointer call_data; /* widget specific data */ { Widget toplevel; toplevel = ToplevelGet (gw); XtUnmapWidget (toplevel); /* make it disappear quickly */ XtDestroyWidget (toplevel); exit (0); } One can see that the above code exit's immediately after destroying the toplevel widget. The trouble is the phase 2 destruction may never occur. This works for most widgets and most applications but will not work for those widgets that have any external state. You might think that since it works now it will always work but remember that part of the reason an object oriented approach is used is so one can be ignorant of the implementation details for each widget. Which means that the widget may change and someday require that some external state is cleaned up by the Destroy callbacks. One alternative is to modify ExitCallback() to set a global flag and then test for that flag in a private event loop. However, private event loops are frowned upon because it tends to encourage sloppy, and difficult to maintain practices. Try the following code instead. #include <X11/Intrinsic.h> extern Widget ToplevelGet ( #if NeedFunctionPrototypes Widget gw #endif ); extern Boolean ExitWorkProc ( #if NeedFunctionPrototypes XtPointer closure #endif ); extern void ExitCallback ( #if NeedFunctionPrototypes Widget gw, XtPointer closure, XtPointer call_data #endif ); Widget ToplevelGet (gw) Widget gw; /* widget to find toplevel */ { Widget top; for (top = gw; XtParent (top); top = XtParent (top)) /* empty */; return (top); } void ExitCallback (gw, closure, call_data) Widget gw; /* widget */ XtPointer closure; /* data the app specified */ XtPointer call_data; /* widget specific data */ { Widget toplevel; toplevel = ToplevelGet (gw); XtUnmapWidget (toplevel); /* make it disappear quickly */ XtDestroyWidget (toplevel); XtAppAddWorkProc (XtWidgetToApplicationContext (gw), ExitWorkProc, (XtPointer) NULL); } Boolean ExitWorkProc (closure) XtPointer closure; { exit (0); /*NOTREACHED*/ } ExitCallback() adds a work procedure that will get called when the application is next idle -- which happens after all the events are processed and the destroy callbacks are executed. ---------------------------------------------------------------------- 11. How do I resize a Shell widget? ---------------------------------------------------------------------- After it is realized, one doesn't resize a Shell widget. The proper thing is to resize the currently managed child of the Shell widget using XtSetValues(). The geometry change is then propagated to the Shell which asks the window manager which may or may not allow the request. However, the Shell must have the resource XtNallowShellResize set to True otherwise it will not even ask the window manager to grant the request and the Shell will not resize. To change the position of a Shell, use XtSetValues() on the Shell, not the child, and within the limits of the window manager it should be granted. ---------------------------------------------------------------------- 12. Why can't XtAppAddInput() handle files? ---------------------------------------------------------------------- It does, however Unix semantics for when I/O is ready for a file does not fit most peoples' intuitive model. In Unix terms a file descriptor is ready for reading whenever the read() call would not block, ignoring the setting of optional flags that indicate not to block. This works as expected for terminals, sockets and pipes. For a file the read() will always return but the return indicates an EOF -- i.e. no more data. The result is the code in the Intrinsics always calls the input handler because it always thinks something is about to be read. The culprit is the select() system call or on SYSV based OS's it is the poll() system call. How to get around this on a Unix system? The best approach is to use another process to check for available input on the file. Use a pipe to connect the application with this other process and pass the file descriptor from the pipe to XtAppAddInput(). A suitable program on BSD systems is "tail -f filename". It's rumored that select() on some systems is not _completely_ reliable. In particular: - IBM AIX 3.1: this is one where it would work for a while (several thousand times) and then stop until some other event woke it up. This seemed to be the result of a race condition in the Kernel. IBM claims to have a fix for this. - Pyramid, doesn't work at all. - Ultrix (and possibly others where pipes are implemented as sockets), wasn't completely broken, but although the writing side wrote in 512 byte blocks the reading side received it all broken up as if it was being put into the pipe a byte at a time. You can waste a lot of time by reading small blocks (get raound it by detecting the situation and having select() ignore the pipe for 10 mseconds - by then it had been given the whole block). Note that all the above descriptions used Unix terminology such as read(), file descriptor, pipes, etc. This is an OS dependent area and may not be identical on all systems. However the Intrinsic designers felt it was a common enough operation that it should be included with part of the toolkit. Why they didn't also deal with signals at this point I don't know. ---------------------------------------------------------------------- 13. What good books and magazines are there on Xt? ---------------------------------------------------------------------- I have a favorite that is the definitive reference. To my perspective it offers a reasonable introduction but also goes into the full details of the Intrinsics. When I started using it I was already familiar with Xt and the concepts behind it, so newcomers may or may not find it useful. I've always found it accurate and complete, which means its a 1000 pages. Asente, Paul J., and Swick, Ralph R., "X Window System Toolkit, The Complete Programmer's Guide and Specification", Digital Press, 1990, ISBN 1-55558-051-3, order number EY-E757E-DP; and by Prentice-Hall, ISBN 0-13-972191-6. Also available through DEC Direct at 1-800-DIGITAL. The other book I commonly recomend to novices is: Young, Doug. "The X Window System: Applications and Programming with Xt (Motif Version)," Prentice Hall, 1989 (ISBN 0-13-497074-8). (ISBN 0-13-972167-3) And of course O'Reilly has an entire series of manuals on X and Xt. O'Reilly ordering is 800-998-9938. In particular, Volume 5 is an Xt reference done in manual page style. The 3rd edition is extensively overhauled and goes far beyond the MIT manual pages. I'm finding it very useful. In particular, the permutted index and references to other manual pages help a great deal in chasing down related information. I read two periodicals, "The X Resource" and the "The X Journal". These are the only two dealing specifically with X. "The X Resource" is published quarterly, by O'Reilly, with one of the issues being the MIT X Consortium Technical Conference Proceedings. There is no advertising. I've found it informative with pretty good depth. For orders, call 1-800-998-9938, or email cathyr@ora.com. For editorial matters, email adrian@ora.com. Table of contents are posted at math.utah.edu in ~ftp/pub/tex/bib in TeX form and on ftp.uu.net in ~ftp/published/oreilly/xresource in ASCII form. "The X Journal" is a bimonthly trade rag with lots of advertising. The articles are informative and oriented toward a less technical audience. I read it more to see what's going on then with an expectation of learning a great deal (but remember, I represent a fairly small percentage of people). Also, they have a pretty good collection of people on the advisory board and as columnists. Call (908) 563-9033. ---------------------------------------------------------------------- 14. What Widgets are available? ---------------------------------------------------------------------- There are three popular widget sets: Athena - The set provided with X11. This is sufficient for most purposes but is on the ugly side. Recently, a 3d look is available for ftp on export.lcs.mit.edu:/contrib/Xaw3d.tar.Z. Motif - From OSF available for a license fee and commonly shipped on many workstation vendors platforms (almost everyone but Sun). It looks good and works well but personally I think it is poorly implemented. OLIT - The Open Look Intrinsics Toolkit is a set of widgets implementing Sun's Open Look specification. Developed by AT&T. I've never used it so can't comment on its quality. I've heard rumours that it is a pain to actually get. In addition the following collection of widgets are also available: Xtra - a library of widgets for sale from Graphical Software Technology (310-328-9338). It includes bar graph, stacked bar graph, line graph, pie chart, xy plot, hypertext, help, spreadsheet, and data entry form widgets. I've never seen them so I can't comment. FWF - The Free Widget Foundation is attempting to collect a set of freely available widgets. Included are a Pixmap editor, FileDialog, and a few others. The current set of widgets can be obtained via anonymous ftp from the machine a.cs.uiuc.edu (128.174.252.1) in the file pub/fwf.shar.Z. Xcu - The Cornell University widgets from Gene Dykes. One of the early widget sets released. Provides a nice appearance for buttons and has a mini command language. Probably not so widely used. Xs - The Sony widget set. This was around during R3 days but seemed to disappear. It looked like it had promise. Xw - The HP widgets. The precursor to Motif. Originally written for R3 there exists diffs to get it to work under R4 & R5. Again, a pretty good widget set but has more or less died. The precursor to this was the Xray toolkit which was originally implemented for X10R4 and apparently provided much experience for the designers of Xt. Xo - A widget set I'm working on. It's still primitive but you can give it a try in archive.cis.ohio-state.edu:pub/Xo/* The following specialized widgets are also available: Tbl - Implements a tabular layout of widgets. Supports Motif widgets as children. Part of Wcl. Plots - The Athena Plotting widgets (not the Athena widgets). Contact gnb@bby.oz.au or joe@Athena.MIT.EDU. ---------------------------------------------------------------------- 15. What alternatives to the Intrinsics are there? ---------------------------------------------------------------------- __________________________________________ Name Language Vendor __________________________________________ Xview C Sun OI C++ ParcPlace Interviews C++ Stanford __________________________________________ However much I like C and admire the skill in both designing and implementing the Intrinsics, hopefully some alternative will develop in the next 3-5 years that uses an object oriented language. Keep your eyes open and expect some change about the same time a language other than C _starts_ gaining acceptance. ---------------------------------------------------------------------- 16. How do I pass a float value to XtSetValues? ---------------------------------------------------------------------- First, what is going wrong is the structure for an Arg is (essentially) typdef struct { String name; long value; } Arg; and the code: Arg arg; XtSetArg (arg, "name", 3.2) expands to Arg arg; arg.name = "name"; arg.value = 3.2; you can see that with normal C type conversions, the arg.value gets the integer "3" instead of the floating point value "3.2". When the value is copied into the widget resource, the bit pattern is wildly different than that required for a floating point value. So, how to get around this? The following macro is from the Athena widgets document and I am now recomending it over the previous suggestions. #define XtSetFloatArg(arg, n, d) \ if (sizeof(float) > sizeof(XtArgVal)) { \ XtSetArg(arg, n, &(d)); \ } else { \ XtArgVal *ld = (XtArgVal *)&(d); \ XtSetArg(arg, n, *ld); \ } ---------------------------------------------------------------------- 17. +++How do I write a resource converter? ---------------------------------------------------------------------- See section 9.6 of the Xt specification, and/or, start with a previously written resource converter, and modify it. ---------------------------------------------------------------------- 18. How do I open multiple displays? ---------------------------------------------------------------------- See "Multi-user Application Software Using Xt", The X Resource, Issue 3, (Summer 1992) by Oliver Jones for a complete coverage of the issues involved. Most of this answer is based on that article. In a nutshell, one uses XtOpenDisplay() to add each display to a _single_ application context and then XtCloseDisplay() to shutdown each display and remove it from the application context. The real problems occur when trying to close down a display. This can happen 3 ways: 1. User selects a "quit" button on one of the displays, 2. User has window manager send a WM_DELETE_WINDOW message, 3. Server disconnect -- possibly from a KillClient message, server shutdown/crash, or network failure. I'll assume you can deal gracefully with 1 & 2 since it is _merely_ a problem of translating a Widget to a display and removing that display. If not, then read the Oliver Jones article. The third one is difficult to handle. The following is based on the Oliver Jones article and I include it here because it is a difficult problem. The difficulty arises because the Xlib design presumed that an I/O error is always unrecoverable and so fatal. This is essentially true for a single display X based application, but not true for a multiple display program or an application that does things other than display information on an X server. When an X I/O error occurs the I/O error handler is called and _if_ it returns then an exit() happens. The only way around this is to use setjmp/longjmp to avoid returning to the I/O error handler. The following code fragment demonstrates this: #include <setjmp.h> jmp_buf XIOrecover; void XIOHandler (dpy) Display *dpy; { destroyDisplay (dpy); longjmp (XIOrecover, 1); } main () { ... if (setjmp (XIOrecover) == 0) XSetIOErrorHandler (XIOHandler); XtAppMainLoop (app_context); } The destroyDisplay() is something that given a Display pointer can go back to the application specific data and perform any necessary cleanup. It should also call XtCloseDisplay(). For those of you unfamiliar with setjmp/longjmp, when setjmp() is first called it returns a 0 and save's enough information in the jmp_buf that a latter execution of longjmp() can return the program to the same state as if the setjmp() was just executed. The return value of this second setjmp() is the value of the second argument to longjmp(). There are several caveats about using these but for this purpose it is adequate. Some other problems you might run into are resource converters that improperly cache resources. The most likely symptoms are Xlib errors such as BadColor, BadAtom, or BadFont. There may be problems with the total number of displays you can open since typically only a limited number of file descriptors are available with 32 being a typical value. You may also run into authorization problems when trying to connect to a display. There was much discussion in comp.windows.x about this topic in November of 91. Robert Scheifler posted an article which basically said this is the way it will be and Xlib will not change. ---------------------------------------------------------------------- 19. What changed from R3 to R4 to R5? ---------------------------------------------------------------------- This addresses only changes in the Intrinsics. First, the general changes for each release are described. Then a, certainly incomplete, list of new functions added and others that are now deprecated are listed. Brevity is a primary goal. Much of the following information is retrieved from Chapter 13 of the MIT Xt Intrinsics Manual and from O'Reilly Volume 5, 3rd edition. From R3 to R4 - Addition of gadgets (windowless widgets) - New resource type converter interface to handle cacheing and additional data. - Variable argument list interface. - #define XtSpecificationRelease 4 (added with this release) - WMShellPart, TopLevelShellPart & TransientShellPart changed incompatibly. - core.initialize, core.set_values added ArgList and count parameters - event handlers had continue_to_dispatch parameter added - core.set_values_almost specification changed. - core.compress_exposure changed to an enumerated data type from Boolean - core.class_inited changed to enumerated data type from Boolean - constraint.get_values_hook added to extension record - core.initialize_hook obsolete as info is passed to core.initialize - shell.root_geometry_manager added to extension record - core.set_values_hook obsolete as info is passed to core.set_values - Calling XtQueryGeometry() must store complete geometry. - Added UnrealizeCallback. - XtTranslateCoords() actually works under R4. From R4 to R5: - Psuedo resource baseTranslation added. - Searching for app-default, and other files, made more flexible - customization resource added. - Per-screen resource database. - Support permanently allocated strings. - Permanetly allocated strings required for several class fields. - The args argument to XtAppInitialize, XtVaAppInitialize, XtOpenDisplay, XtDisplayInitialize, and XtInitialize were changed from Cardinal* to int* - Many performance improvements (this is summarized from the article "Xt Performance Improvements in Release 5" by Gabe Beged-Dov in "The X Resource", Issue 3): - XrmStringToQuark() augmented with XrmPermStringToQuark() to avoid string copies. Several fields in the class record are indicated as needing permanent strings. - Using an array of Strings for resources - Callback lists redesigned to use less memory - Translation manager redesigned and rewritten so it takes less memory, translation tables merges are faster, cache of action bindings - Keycode to Keysyms are cached. - Better sharing of GC's with modifiable fields - Window to Widget translation uses less space and faster - Does not malloc space for widget name since quark is available - Widget space is allocated to include the constraints - Over several example programs, about a 26% reduction in memory usage. Functions new with R5: ---------------------- XtAllocateGC() - sharable GC with modifiable fields XtGetActionList() - get the action table of a class XtScreenDatabase() - return resource database for a screen XtSetLanguageProc() - register language procedure called to set locale Functions new with R4: ---------------------- XtAppAddActionHook() - procedure to call before _every_ action. XtAppInitialize() - lots of initialization work. XtAppReleaseCacheRefs() - decrement cache reference count for converter XtAppSetFallbackResources() - specify default resources XtAppSetTypeConverter() - register a new style converter XtCallCallbackList() - directly execute a callback list XtCallConverter () - invoke a new style converter XtCallbackReleaseCacheRef() - release a cached resource value XtCallbackReleaseCacheRefList() - release a list of cached resource values XtConvertAndStore() - find and call a resource converter XtDirectConvert() - Invoke old-style converter XtDisplayOfObject() - Return the display XtDisplayStringConversionWarning() - issue a warning about conversion XtFindFile() - Find a file XtGetActionKeysym() - Retrieve keysym & modifies for this action XtGetApplicationNameAndClass() - return name and class XtGetConstraintResourceList() - get constraints for a widget XtGetKeysymTable() - return keycode-to-keysym mapping table XtGetMultiClickTime() - read the multi-click time XtGetSelectionRequest() - retrieve the SelectionRequest event XtGetSelectionValueIncremental() - obtain the selection value incrementally XtGetSelectionValuesIncremental() - obtain the selection value incrementally XtInitializeWidgetClass() - initialize a widget class manually XtInsertEventHanlder() - register event handler before/after others XtInsertRawEventHandler() - register event handler without modify input mask XtIsObject() - test if subclass of Object XtIsRectObj() - test if subclass of RectObj XtKeysymToKeyCodeList() - return list of keycodes XtLastTimestampProcessed() - retrieve most recent event time XtMenuPopdown - Action for popping down a widget XtMenuPopup - Action for popping up a widget XtOffsetOf - macro for structure offsets XtOwnSelectionIncremental() - make selection data availabe incrementally XtPoupSpringLoaded() - map a spring-loaded popup XtRegisterGrabAction() - indicate action procedure needs a passive grab XtRemoveActiohHook() - remove function called after every action XtResolvePathname() - find a file XtScreenOfObject() - return screen of object. XtSetMultiClickTime() - set the multi-click time XtSetWMColormapWindows() - set WM_COLORMAP_WINDOWS for custom colormaps XtUngrabButton() - cancel a passive button grab XtUngrabKey() - cancel a passive key grab XtUngrabKeybard() - release an active keyboard grab XtUngrabPointer() - release an active pointer grab XtVa*() - varags interfaces to a bunch of functions XtWindowOfObject() - return Window of nearest widget ancestor Deprecated Replacement When ---------------------------------------------------------------------- XtAddActions() XtAppAddActions() R3 XtAddConverter() XtAppAddConverter() R3 XtAddInput() XtAppAddInput () R3 XtAddTimeout() XtAppAddTimeout() R3 XtAddWorkProc() XtAppAddWorkProc() R3 XtConvert() XtConvertAndStore() R4 XtCreateApplicationShell XtAppCreateShell() R3 XtDestroyGC() XtReleaseGC() R3 XtError() XtAppError() R3 XtGetErrorDatabase() XtAppGetErrorDatabase R3 XtGetErrorDatabaseText() XtAppGetErrorDatabaseText R3 XtGetSelectionTimeout() XtAppGetSelectionTimeout R3 XtInitialize() XtAppInitialize() R3 XtMainLoop() XtAppMainLoop() R3 MenuPopdown(action) XtMenuPopdown(action) R4 MenuPopup(action) XtMenuPopup(action) R4 XtNextEvent() XtAppNextEvent() R3 XtPeekEvent() XtAppPeekEvent() R3 XtPending() XtAppPending() R3 XtSetErrorHandler() XtAppSetErrorHandler() R3 XtSetErrorMsgHandler XtAppSetErrorMsgHandler() R3 XtSetSelectionTimeout() XtAppSetSelectionTimeout() R3 XtSetWarningHandler() XtAppSetWarningHandler() R3 XtSetWarningMsgHandler() XtAppSetWarningMsgHandler() R3 XtWarning() XtAppWarning() R3 XtWarningMsg() XtAppWarningMsg() R3 ---------------------------------------------------------------------- 20. Where are the resources loaded from? ---------------------------------------------------------------------- The resources of a widget are filled in from the following places (from highest priority to lowest priority): 1. Args passed at creation time. 2. Command line arguments. 3. User's per host defaults file 4. User's defaults file. 5. User's per application default file. 6. System wide per application default file. Note that 2-6 are read only once on application startup. The result of steps 3-6 is a single resource database used for further queries. The per host defaults file contains customizations for all applications executing on a specific computer. This file is either specified with the XENVIRONMENT environment variable or if that is not set then the file $HOME/.Xdefaults-<host> is used. The user defaults file is either obtained from the RESOURCE_MANAGER property on the root window of the display or if that is not set then the file $HOME/.Xdefaults is used. Typically, the program "xrdb" is used to set the RESOURCE_MANAGER property. Please note that this should be kept relatively small as each client that connects to the display must transfer the property. A size of around 1-3KByte is reasonable. Some toolkits may track changes to the RESOURCE_MANAGER but most do not. A user may have many per application default files containing customizations specific to each application. The intrinsics are quite flexible on how this file is found. Read the next part that describes the various environment variables and how they effect where this file is found. The system wide per application default files are typically found in /usr/lib/X11/app-defaults. If such a file is not found then the fallback resources are used. The intrinsics are quite flexible on how this file is found. Read the next part that describes the various environment variables and how they effect where this file is found. [Thanks to Oliver Jones (oj@pictel.com) for the following, 6/92] You can use several environment variables to control how resources are loaded for your Xt-based programs -- XFILESEARCHPATH, XUSERFILESEARCHPATH, and XAPPLRESDIR. These environment variables control where Xt looks for application-defaults files as an application is initializing. Xt loads at most one app-defaults file from the path defined in XFILESEARCHPATH and another from the path defined in XUSERFILESEARCHPATH. Set XFILESEARCHPATH if software is installed on your system in such a way that app-defaults files appear in several different directory hierarchies. Suppose, for example, that you are running Sun's Open Windows, and you also have some R4 X applications installed in /usr/lib/X11/app-defaults. You could set a value like this for XFILESEARCHPATH, and it would cause Xt to look up app-defaults files in both /usr/lib/X11 and /usr/openwin/lib (or wherever your OPENWINHOME is located):